fix(directus): ticket invoice schema follow-up (user_created FK, read-only invoice links) - #257

Requested by Dennis Becker · Slack thread

Before: In production, ticket_invoices.user_created is a bare UUID. It has no foreign key and no relation to directus_users, even though #248's hand-written snapshot declared one. In the App, the ticket_orders.invoices O2M can be edited. Deselecting an invoice would try to set its order to null, which fails because the column is NOT NULL. "Select existing" could move an invoice document to a different order. The legacy pointers ticket_orders.invoice_number and invoice_file can also be edited by hand, although the bundle maintains them (current-document pointer, invoice numbering, backfill).

After: ticket_invoices.user_created gets a real FK and relation to directus_users.id. ticket_orders.invoices, invoice_number and invoice_file are read-only in the App, with notes explaining why. No fields, relations or data are removed.

How: These are hand edits to directus-cms/schema.json on top of the production snapshot from #251, in the same format:

• The new relation is modeled on the other 39 user_created/user_updated relations. It uses the same <table>_user_created_foreign naming, one_deselect_action: nullify and ON DELETE NO ACTION.
• The field-level foreign_key_table/foreign_key_column is set to match.
• readonly in field meta only affects the App. The bundle writes these fields through ItemsService, and that keeps working.

Depends on #251. This branch is based on #251's snapshot commit, so please merge #251 first; this diff then shrinks to the single commit here. After merging, run directus schema apply against production.

Before applying, check that there are no orphaned creator IDs, otherwise adding the FK fails:
SELECT count(*) FROM ticket_invoices t LEFT JOIN directus_users u ON u.id = t.user_created WHERE t.user_created IS NOT NULL AND u.id IS NULL; (expected result: 0)

Validation:

• Ran locally with Directus 11.17.4 and Postgres 16. On a fresh DB with chore(directus): update production schema snapshot #251's snapshot applied, schema apply --dry-run lists exactly these field and relation changes, plus two baseline items that the chore(directus): update production schema snapshot #251 snapshot also shows (asset_templates.variables_schema and social_media_posts.tags "special → null"). These two are unrelated to this PR.
• The real apply succeeded and created ticket_invoices_user_created_foreign.

Review points

• Addressed: the Codex point to restore the invoice creator FK and relation.
• Addressed: the Copilot point that order is non-nullable while the O2M uses nullify. Instead of changing the deselect action (the only other option, delete, would be destructive), the O2M is now read-only, so documents can't be detached or re-linked. The DB-level ON DELETE NO ACTION on order stays. Blocking the deletion of an order that has invoices is intended.
• Addressed (partly): the Copilot point about legacy order-level invoice fields. They are not removed, because the bundle still reads and writes them (issueOriginalInvoice, generateInvoiceNumber, lifecycle regenerate, backfill). They are now read-only and labelled as maintained automatically.
• Deliberately not changed: sent_at read-only. The ticket-order-processing hook's Slack alert tells admins to set sent_at manually when stamping it fails after the email went out, so it has to stay editable in the App.
• Deliberately not changed: user_created uses ON DELETE NO ACTION, not SET NULL. This matches every other user relation in the schema and keeps the audit attribution. A user who created invoice documents has to be suspended rather than hard-deleted.
• Deliberately not changed: the other Copilot nitpicks (archive_app_filter without an archive field, the column name order, the index on type, invoice_number being required and read-only). They are cosmetic or would mean a disruptive rename.

🤖 Generated with Claude Code

https://claude.ai/code/session_01G9qwzY9WrCDrT5NX7zNP1E

Generated by Claude Code